A further approach is to look at the likely ranges of possible numerical solutions to the Riddle. There are an awful lot of possible IP addresses out there - potentially 1.5+ billion. The vast bulk of these have not been allocated (give 'em time!), but even those that do exist are multitudinous.

It would be helpful if we could narrow down the potential target list and get some feel for what are likely addresses.

This shouldn't be too difficult, because there are only a limited set of possible numbers coming out of the Riddle, and there are only a limited number of things you can do with these numbers.

Here are some preliminary thoughts. If you think I've overlooked anything (which is overwhelmingly likely), let me know.

First, what can we do to the "URL" to reveal the real address?

Well, from the Riddle, we get a series of possible numbers - five rows of five columns, with several possible entries in each cell.

We can ADD, SUBTRACT, AND, OR, XOR them with the URL, and conceivably MULTIPLY or DIVIDE.

However, we must finish up with numbers in the URL that are between 0 and 255. In practice, the restriction is greater -- see below. This is useful, as it cuts out procedures that run over the limit. And if a procedure generates a number outside the range in one part of the URL, we can rule out the whole URL.

[Aside] The reason for doing this is to try and seek inspiration when you see a URL somewhere that makes you say: hey, that looks suspicious... I wonder if he's hiding in there? If you have a list of possible addresses, you can quickly decide whether to take the idea further. In other words, I want to be able to rule out dead ends. I think Sherlock Holmes was supposed to have said "When you have eliminated the impossible, that which remains, however improbable, must be the truth".

Well, it may not be that simple, but that's the general idea. [/Aside]

I've added to this discussion from a very helpful summary I received from Hackmore Readrite. I've copied his message on URL numbering here, as a guide to +ORC Riddle hunters because I think it is interesting in its own right as a summary of what numbers you can have in URLs. Of course, many of you may already know this stuff. But for those (like me) who hadn't found it yet...

Let's get down to business.

In the first octet (digit group) of a URL, we need to restrict our results to between 128 and 223. I'm ignoring the large "Class A" networks with first octet allocations below 127 (see Hackmore's discussion) but we need to keep this in mind, just in case...

In the second, third and fourth octet, you can have the numbers 1 to 254.

This allows a total address range (ignoring the "Class A" groups) of 95*254*254*254, or 1.56 billion possible URLs.

That's a lot. We need to find ways of trimming the targets down a bit. What I want to do now is to explore the likely number combinations that come of of the Riddle

I'm going to start with the first column, but not all the different interpretations that I listed in the main Riddle discussion, because, frankly, I think some of them are fanciful, and I want to keep this task manageable.

So what options are there? Looking at the previous discussion, I'm only taking, here, the "gold, silver, bronze" ranking and the word lengths. These give us [1,2,2,3,3] and [4,6,6,5,5]. Just to be difficult, I'll also take the alphabetical sequence of the first letter (G=7, S=19). That gives us the further sequence [7,19,19,19,19]. I could also take the ASCII value of G and S, and that would give us [71,83,83,83,83]. I don't like them so much as they're quite large and they start running us close to the 255 limit.

Next, the second column. To me, this seems the most important column, the one I think might play a key role in the decoding. Taking simply the number of bars, we get the column [6,5,4,0,(0)]. I think you have to assume that no mention is the same as zero, but I'm not sure about this. If you take the "bars" as meaning binary "ones" then we have six bars as 63, five as 31 etc, as before, and that gives us the column [63,31,15,0,(0)].

The third column is, I think, binary in nature. I assume "raised" is the same as "open" -- though I know others haven't assumed this -- and that closed is the opposite. If raised =1, we have the column [1,(0),1,1,0]. Otherwise we have [0,(0),0,0,1]. I'm also assuming that the blank entry is zero in both cases. Now I'm not completely sure that "raised" is actually a digit. It might indicate bit shifting in the previous column (or perhaps addition by it), for example. But let's proceed for the moment.

The fourth column, full face or profile: I'm assuming that full face is 1 and profile is 0. But, as others have pointed out, this may also be a modifier, not a digit. If it is a digit, we get the column [1,1,0,1,0]

The fifth column leaves me cold. I think it's just noise. But if the number of "users" is the clue, we have [1,2,3,2,2].

This allows us to compile a table of the columns we have just generated (this time reading down the page, not across it as above):

metal        bars    visor    face   users
1,4, 7,71    6,63     1,0      1       1
2,6,19,83    5,31     0,0      1       2
2,6,19,83    4,15     1,0      0       3
3,5,19,83    0,0      1,0      1       2
3,5,19,83    0,0      0,1      0       2

OK, what do we do with them?

Well, we can use them one at a time, all together, or look at one or more columns as modifiers to what we do with the others.

We have a matrix of five rows and five columns, with a variety of candidates in each column. I think we need to apply the matrix to a URL "vector" with five elements. (What other options are there? What do you leave out?)

We can process the URL groups broken into four groups plus the suffix: 131-092-015-128-+ORC, or we can assume the suffix is not changed and break the URL up into five groups of two digits: 13-19-21-51-28 .

I'm inclined to apply each row to a particular part of the URL group. Thus you would apply row 1 to 131 (or 13), row 2 to 092 (or 19), etc.

The simplest approach is just to add all the figures to the URL digits. Taking the first candidate in each column and the three-number groupings, for instance, we have:

131 + 1 + 6 + 1 + 1 + 1 = 142
092 + 2 + 5 + 0 + 1 + 2 = 102
015 + 2 + 4 + 1 + 0 + 3 = 025
128 + 3 + 0 + 1 + 1 + 2 = 135

or the URL IP address 142.102.025.135 . (No, it doesn't work).

Quite what you do with the string "+ORC" I don't know. But the fifth row in the matrix is mainly zeros except for the first and last columns. Adding together the digits in all elements of the last row (choosing the first option in each case) gives us 5. Adding this to the ASCII value of each of the string characters gives us "0TWH" in place of "+ORC". Whatever we do, the string must contain a useable set of characters, however odd.

In fact, this last element may be a fruitful area to explore: generate a series of possible strings from "+ORC" and then do a Hotbot search for the string. Might be a lot quicker than stuffing around Ping-ing everything in site. And I've already searched for "+ORC" without success -- haven't we all?

Well, now back to the calculations, this time using the "bars".

Let's look at the "bars" as if they are binary "ones". As a start, ignoring the other elements of the Riddle, let's convolve the four URL octet digits with 6, 5, 4, and 0 bars, or [00111111, 00011111, 00001111, 00000000] in binary and [63,31,15,0] decimal. To do this visually for the logical (AND, OR, XOR) combinations, I'll also convert the URL to binary: [10000011, 01011100, 00001111, 10000000].

Now let's try various ways of combining the binary URL with the binary "bars". First, let's use AND:

[00111111, 00011111, 00001111, 00000000]
 AND
[10000011, 01011100, 00001111, 10000000]
 =
[00000011, 00011100, 00001111, 00000000]

This is unsatisfactory for two reasons. First, the first octet is less than 128, and second, the final octet is zero. Both ruled out (see Hackmore's note). So "AND"-ing the numbers doesn't work.

Let's try XOR:

[00111111, 00011111, 00001111, 00000000]
 XOR
[10000011, 01011100, 00001111, 10000000]
 =
[10111100, 01000011, 00000000, 10000000]

Next, let's try OR:

[00111111, 00011111, 00001111, 00000000]
 OR
[10000011, 01011100, 00001111, 10000000]
 =
[10111111, 01011111, 00001111, 10000000]

And next, addition, but let's do it in decimal, for heaven's sake:

[131,92,15,128] + [63,31,15,0] = [194,123,30,128]

or a URL of 194.123.30.128, also acceptable.

And finally, subtraction (in decimal, in reversed order - let's not add to the mess with negative numbers):

[131,92,15,128] - [63,31,15,0] = [68,61,0,128]

which is unacceptable as a URL because of the zero and the low leading number.

Multiplication and division blow the numbers out way over 254, so forget them. Using NAND and NOR also give us numbers outside the acceptable range, in case you thought of them. And doing subtraction in normal order, even ignoring the carry bits, still gives us an unacceptable zero in the third octet, so we can forget it too.

So there are two possible URLs from this exercise, 191.95.15.128 and 194.123.30.128 .

Well, this may give you a flavor of how to generate numbers for the candidate URLs. We have the option now of adding some of the other column digits. These generate URLs like:

192.95.16.129 and 195.123.31.129 by adding in the visor column (first 4 rows)
192.96.15.129 and 195.124.30.129 by adding in the face column (first 4 rows) and
193.96.16.130 and 196.124.31.130 by adding in both.

I've ignored the implications of the fifth row for this last example. But you can see there are a fair number of possible URL candidates that you can generate in one way or another. The task now is to try and generate as many plausible candidates as possible and test them all! (Ugly but necessary in the absence of inspiration).

I'm not sure where this leaves me: I think it's pencil and paper time. But I'm likely to extend this page starting at this point over the forthcoming weeks, as I get inspiration, so come back and see what's happened.

----------------------

Also this is where I need your help. In the absence of further, merciful guidance from +ORC, we have the task of exploring all these combinations, even if only to rule them out. If you feel like "Ping-ing" the various possible combinations to see if there's anyone home, we could cover a lot of ground. We need a list of combinations that actually respond to a Ping. They're our shortlist.

Given the total possible number of URLs (1.56 billion) and assuming that 16 million computers on the Internet each have a unique IP address, suggests at random about 1 in 100 URL combinations should answer a Ping (assuming they're not off line!) If we look at recent Internet surveys, only about one in five registered URLs actually answers a Ping, so that extends the odds to a bit less than 1 in 500. If we shorten the odds by assuming only initial combinations between 128 and 223 (see Hackmore's note), the overall chance of getting an answer is around 1 in 200. So any answer at all is by definition rare and interesting. (I've only found one, so far, which turns out to be a Children's clinic in Germany!)

What I'd like to suggest is that if you have the inclination, try Ping-ing the combinations and make a list of those that don't answer (the vast majority) and those that do. If several +ORC-seekers cover the same ground, so much the better, as we double check and cover possible temporary outages.

I know this is very brute-force, and thoroughly non-Zen, but in the absence of inspiration all we have left is perspiration. Sudo non inspiror, if I can remember the conjugations and passives through the haze of years ( I can hear Cicero squirm, and probably +ORC). Let's keep Latin alive, by creating totally unexpected words, anyway!

The next step, dear reader, is up to you. Let me know what you do or don't find. Both are important.